Replace deprecated rgb_order with channel_colors - #74
Conversation
ESPHome 2026.8.0 replaces rgb_order/is_rgbw/is_wrgb with a single channel_colors key on esp32_rmt_led_strip (esphome#18474).
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (7)
🚧 Files skipped from review as they are similar to previous changes (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughThe ESPHome configurations now require ESPHome 2026.8.0. The Core configuration updates its version substitution and replaces ChangesESPHome configuration updates
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This updates the ESPHome configuration to the current channel-color format and required version without changing intended LED behavior. No actionable merge-blocking risk remains beyond normal checks and review. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (7 skipped: 7 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
`channel_colors` only exists from ESPHome 2026.8.0 (esphome#18474), but these YAMLs still declared an older min_version. Devices adopted through the ESPHome dashboard track this repo at HEAD with no pinned ref, so on an older ESPHome the next recompile fails with "Unknown option channel_colors" pointing into a file the user never wrote, instead of a clear version error. ESPHome merges remote packages and checks min_version in the preload phase, before component schemas load, so the bump produces the right message. No firmware change: min_version is validation-only and emits no code, so the compiled binary is unaffected. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
bharvey88
left a comment
bharvey88
left a comment
There was a problem hiding this comment.
Verified against upstream rather than the description: channel_colors landed in ESPHome 2026.8.0 (esphome#18474), and rgb_order still validates but is marked for removal in 2027.3.0. validate_channel_colors uppercases its input and channel_colors_struct derives the same r/g/b indices, so GRB here is byte-identical to the previous grb. No behaviour change and no change to the compiled binary.
Every esp32_rmt_led_strip block in this repo is covered. I pushed one commit on top bumping min_version to 2026.8.0: devices adopted through the ESPHome dashboard track this repo at HEAD with no pinned ref, so without it an adopter on an older ESPHome would hit Unknown option channel_colors inside a file they never wrote. ESPHome merges remote packages and checks min_version before component schemas load, so the bump surfaces the right error instead.
CI green on stable, beta and dev.
3 participants
ESPHome 2026.8.0 replaces
rgb_order/is_rgbw/is_wrgbwith a singlechannel_colorskey onesp32_rmt_led_strip(esphome#18474).channel_colorstakes each ofR,G,Bexactly once, optionally with a singleW; the value is case-insensitive. No behaviour change —grbandGRBare equivalent, uppercase to match the ESPHome docs.Summary by CodeRabbit